RED Metrics

Requests

1秒あたりに処理されたリクエスト数

スループットが高ければ負荷がかかり、性能に影響を与えることがある

逆に低ければ、予想より利用されていない可能性がある

Error

失敗したリクエスト数

依存サービスの問題やバグ、設定ミスなど、何か問題が起きていることを示す指標

1つのリクエスト処理にかかる時間

長い処理時間は、リソース不足、非効率なコード、依存関係の遅延などが原因になっている可能性がある

3つは相互に関連している

e.g. リクエスト数（Rate）が増えると、レイテンシ（Duration）が増え、それがタイムアウトなどによるエラー（Errors）の増加につながる

3つをセットで分析することで、システムの挙動をより正確に理解でき、どの部分に最適化や対処が必要かを特定しやすくなる

latency

https://gyazo.com/670851b4adea133062a4a58db7c09970

紫の垂直線は外れ値を表す

大半のリクエストよりも著しく時間がかかったリクエスト

https://gyazo.com/a520dad5c8b0993a86f094ea82bab864

hoverすると、複数のmetricsの関連を確認できる

リクエスト数が増えると処理が重くなり、エラーがあると処理時間が長くなる、とかを推測できる

https://gyazo.com/24e9b99977e776b8206fa09caa390f4d

同じ時点の「% of Time Spent by Downstream Services」グラフでは、下流のpostgresサービスに特別なスパイクは見られません。これは、store-discountsサービスがデータベースの応答待ちによって遅くなっているわけではないことを示しています。これは良い兆候です。

ただし、全体の処理時間のうち、store-discountsサービス自体が約半分を占めていることがわかります。

Traceの時間の使われ具合を可視化したものか

store-discounts が毎回トレース時間の大部分（50〜60%）を消費している

残りの時間は PostgreSQLクエリ（postgres > postgres）に使われている